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(57) Abstract: In order to control the authorisation of a user during 
an attempt to access an IP transport network (5) by means of an access 
network (1, 2), a user terminal (11, 12, 13) emits an access request to 
an access supplier (6, 7, 8), containing data for authenticating the user 
to the access supplier, and said request is then transmitted to an access 
server (9) of the access network (1, 2) in view of being addressed to a 
remote authentication server (15) of the access supplier. On reception 
of the access request, the access server (9) emits a RADIUS request 
to a proxy server (10) of the access network (1, 2) which determines 
whether the user must be locally authenticated, and if this is the case, 
the proxy server transmits, to the access server (9), a request for au- 
thentication data to be addressed to the terminal of the user, and carries 
out a local procedure to authenticate the user, on the basis of the au- 
thentication data supplied by the user. 

(57) Abrege : Pour gerer I'autorisation d'un utilisateur lors d'une ten- 
tative d'acces a un reseau de transport IP (5) par I'intermediaire d'un 
reseau d'acces (1,2), un terminal (11, 12, 13) d'utilisateuremet a desti- 
nation d'un foumisseur d'acces (6, 7, 8) une requete d'acces contenant 

des donnees d' authentification de 1' utilisateur aupres du foumisseur 
d'acces, qui est transmise a un serveur d'acces (9) du reseau d'acces 
(1, 2), en vue d'etre adressee a un serveur d' authentification distant 
(15) du foumisseur d'acces ; sur reception de la requete d'acces, le 
serveur d'acces (9) emet une requete RADIUS a un serveur proxy (10) 
du reseau d'acces (1,2) qui determine si 1' utilisateur doit etre authenti- 
fie localement, et si tel est le cas, le serveur proxy transmet au serveur 
d'acces (9) une demande de donnees d' authentification 
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a adresser au terminal de I'utilisateur, et execute une procedure d'authentification locale de I'utilisateur, sur la base des donnees 
d'authentification foumies par I'utilisateur. 
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PROCEDE ET SYSTEME DE GESTION D^AUTORISATION D^ACCES 
D^UN UTILISATEUR AU NIVEAU D^UN DOMAINE ADMINISTRATIF 
LOCAL LORS D^UNE CONNEXION DE L^UTILISATEUR A UN RESEAU 
5 IR 

La presente iQvention conceme la foumiture de services bases sur un transport 
IP (Intemet Protocol) tels que la connexion au reseau Internet ou la telephonic 
sur IP. 

10 

EUe s'applique notamment aux architectures bashes sur le protocole RADIUS 
(Remote Authentication Dial In User Service) qui sont largement d6ploy6es 
dans les reseaux IP pour g6rer les droits d^accds des utilisateurs et le comptage 
necessaire a la facturation de ces demiers pour un domaine administratif donne. 

15 Dans ce contexte, un domaine adniinistratif regroupe T ensemble des 
equipements reseau geres par xm mSme administrateur reseau. Ces architectures 
sont egalement utilisees pour gerer Pacces aux reseaux des utilisateurs en 
situation d'itinerance (roaming), c'est-a-dire connectes depuis un reseau 
appartenant a un domaine administratif different de celui dont ils dependent, la 

20 gestion de Tautorisation etant alors effectuee entre domaines administratifs. 

Dans le cadre des architectures permettant Faeces a des services IP par 
rinterm6diaire de technologies telles que ADSL (Asymmetric Digital 
Subscriber Line), WLAN (Wheless Local Area Network), et WAP (Wireless 

25 Application Protocol), au moins deux domaiaes administratifs participent k la 
gestion d'autorisation d'acces. II s'agit du domaine adniinistratif local, c'est-a- 
dire celui auquel TutiUsateur se connecte et d'un domaine administratif distant, 
c'est-a-dire celxii du foumisseur d'acces au reseau IP ou de services auquel il 
desire acceder. Datis ces architectures, le domaine administratif local joue 

30 essentiellement le role d'intermediaire entre Tutilisateur et le domaine 
administratif de son foumisseur de service. 

Le protocole RADIUS qui est conpu essentiellement sur le modele 
client/serveur, permet de gerer les droits d'acces d'un utilisateur d'un reseau IP. 
35 Dans les architectures mentionnees ci-avant, TutiUsateur se connecte tout 
d'abord a un servexir d'acces d'un reseau local, ce serveur possedant un client 
RADIUS charge de recuperer les informations foumies lors de sa demande 
d'acces et de transmettre ces informations dans un message de type requete 
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d'acces (Access-Request) a un serveur d'authentification du reseau d'acces, 
possedant un serveur RADIUS. Le serveur d'authentification assure le 
traitement des requetes d'acces en authentifiant les utilisateurs en fonction des 
informations dont il dispose, et foumit en reponse, soit une autorisation d'acc^s 
5 sous la foime d'un message d' acceptation d'acces (Access- Accept), soit un 
refus d'acces sous la forme d'un message de refiis d'acces (Access-Reject) 
contenant la raison du refus. Le message d' autorisation d'accds contient toutes 
les informations n6cessaires au serveur d'acces pour foumir le service final a 
Tutilisateur et notamment les informations sur la configuration d'accds. 

10 

En plus des messages mentionnes ci-avant, le protocole RADIUS prevoit 
6galement un message de d^fi d'acces (Access-Challenge) permettant au 
serveur d'authentification d'envoyer au serveur d'acces une valeur de defi non- 
predictible. A la reception d'un tel message, le serveur d'acces demande a 

15 Futilisateur de lui foumir une valexir de reponse obtenue en appliquant a la 
valeur de defi un algorithme predefini. Sur reception de cette reponse, le serveur 
d'acces emet a destination du serveur d'authentification xm nouveau message de 
requete d'acces contenant la valeur de reponse. Ce nouveau message de requete 
d'acces est traite par le serveur d'authentification qui y repond en envoyant un 

20 message d' acceptation ou de refus d'acces, selon la valeur de reponse foumie 
par Tutilisateur. Le servem* d'authentification pent egalement repondre par un 
message de defi d'acces (Access Challenge) 

Si le serveur d'authentification du reseau d'acces, appele par le serveur d'acces 
26 ne dispose pas des informations necessaires au traitement de la demande 
d'acces emise par Futilisateur, il pent s'adresser a un serveur d'authentification 
approprie en se comportant comme un serveur mandataire (proxy) RADIUS qui 
ne fait que retransmettre les messages entre le serveur d'acces et un autre 
serveur d'authentification, II pent ainsi assurer le role d'aiguillage des messages 
30 RADIUS qui transitent par lui vers plusieurs serveurs d'authentification. II peut 
egalement assurer la fonction de filtrage de ces messages et en modifier le 
contenu (par ajout, suppression ou modification des attributs) sans pour autant 
pouvoir en modifier la nature. 

35 Le role d'un serveur proxy RADIUS tel que prevu dans le protocole RADIUS 
est done tres limite. Or un tel serveur peut avoir besoin d'exercer un controle 
renforce sur la signalisation et eventuellement declencher une authentification 
locale. En particulier, un tel serveur mandataire n'a pas la possibilite d'initier 
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sur reception d'uti message de requdte d'acces rni echange de type defi/reponse 
avec un client RADIUS, et ce independaxnment d'mi serveur d'authentification 
distant. 

5 Dans de nombreuses applications, il est pourtant soxihaitable de pouvoir 
authentifier un utilisateur non seulement au niveau distant, mais egalement au 
niveau local, notamment pour pouvoir proposer aux utilisateurs des services 
supplementaires au niveau local, en plus d'un acces k un reseau public tel que le 
reseau Internet. 

10 

La presente invention a pour but de supprimer ces inconvenients. Get objectif 
est atteint par la provision d'un proc6d6 de gestion d'autorisation d'un utilisateur 
lors d'une tentative d' acces a un reseau de transport IP par rintermddiaire d'un 
reseau d' acces, ce procede comprenant des 6tapes au cours desquelles : 

15 

- un terminal d'utilisateur emet a destination d'mi foumisseur d' acces ou de 
ser\dce IP une requdte d' acces contenant des donnees d'authentification de 
Tutilisateur aupres du foumisseur d' acces ou de service IP, qui est transmise 
par rintermediaire d'un serveur d'acces du reseau d' acces et du reseau de 

20 transport IP, en vue d'etre adressee a un serveur d'authentification distant du 
foumisseur d' acces ou de service IP, 

- sur reception de la requ6te d*acces, le serveur d'acces emet une requdte 
RADIUS conforme au protocole RADIUS a un serveur proxy du r6seau 
d'accds, 

25 - sur reception de la requete RADIUS, le serveur proxy 6niet une demande 
d'autorisation d'accds au serveur d'authentification distant, 

- le serveiH" d'authentification distant execute une procedure d'authentification 
de Tutilisateur, sur la base des donn6es d'authentification contenues dans la 
requdte d'acces, et transmet en reponse au serveur proxy un message de 

30 reponse contenant le resultat de la procedure d'authentification de 
rutilisateur. 

Selon rinvention, ce procede comprend en outre des etapes au cours 
desquelles : 

35 

- le serveur proxy determine pour chaque requete RADIUS, re9ue du serveur 
d^acces et correspondant a ime requete d'acces emise par un terminal 
d'utilisateur, si une authentification locale de Tutilisateur emetteur de la 
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requete d'acces, au niveau du reseau local doit etre effectuee, 

- si une authentification locale de Futilisatexir doit etre effectuee, le serveur 
proxy emet a destination du serveur d^acces une demande de donates 
d' authentification qui est retransmise au terminal de Tutilisateur, re9oit un 

5 message de reponse du terminal d'utilisateur par Tintennediaire du serveur 
d'acces, et execute une procedure d' authentification locale de Putilisateur, 
sur la base des donnees d' authentification contenues dans le message de 
reponse, 

10 Selon un mode de realisation prefere de Tinvention, la demande de donnees 
d'authentification emise par le serveur proxy a destination du terminal de 
I'utilisateur si une authentification locale de Tutilisateur doit etre effectuee, est 
un message de defi contenant un nombre aleatoire. 

15 Avantageusement, le message de defi contient une indication permettant au 
terminal de Putilisateur de determiner qu'il conceme une authentification locale 
de Tutilisateur. 

Selon un mode de realisation prefere de Tinvention, T authentification distante 
20 de Tutilisateur par le serveur d' authentification distant comprend des stapes au 
cours desquelles : 

- le serveur d' authentification distant emet en direction de I'utilisateur un 
message de defi contenant un nombre aleatoire, 

25 - le serveur proxy retransmet le message de defi emis par le serveur 
d' authentification distant en direction de I'utilisateur et re9oit dans un 
message de r6ponse les donnees d'authentification de I'utilisateur aupres du 
serveur d'authentification distant, 

- le serveur proxy retransmet au serveur d'authentification distant le message 
30 de reponse emis par le termuial de I'utilisateur, 

- le servexir proxy re9oit du serveur d'authentification distant im message de 
resultat de I'authentification de Tutilisateur. 

Selon un mode de realisation prefere de Tinvention, le serveur proxy determine 
35 quels droits d'acces attribuer a Tutilisateur en fonction du resultat des 
authentifications locale et distante de I'utilisateur. 

L*invention conceme egalement im systeme de gestion d'autorisation d'lm 
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utilisateur lors d'une tentative d'acces d'rni terminal d'utilisatenr a nn 
foumisseur d'acces ou de service IP par rintemiediaire d'un reseau de transport 
IP, le systeme comprenant : 

5 - des reseaux d'acces auxquels sont connect6s les terminaux d'utilisateurs, 

- des passerelles IP assurant la liaison respectivement entre les rfoeaux d'acces 
et le reseau de transport IP, 

- au moins xm serveur d'accds par reseau d'acces, congu pour emettre a la 
demande des tenninaux d'utilisateur des requdtes d'acces RADIUS 

1 0 conformes au protocole RADIUS, 

- au moins un serveur d'authentification distant pour chacun des foumisseurs 
d'acces ou de service IP, con9U pour authentifier les utilisateurs en fonction 
de donnees d'authentification contenues dans des requdtes d'accds repues par 
le serveur d'authentification, et 

15 - un serveur proxy connecte au reseau de transport IP con9u pour retransmettre 
chaque requite d'acces RADIUS, emise par Tun des serveurs d'acces a la 
demande d'un utilisateur, vers un serveur d'authentification distant de 
foumisseur d'acces ou de service IP indique dans la requete d'acces, et 
retransmettre vers les serveiirs d'acces les reponses d'authentification 

20 foumies par les serveurs d'authentification distant. 

Selon Tinvention, le serveur proxy comprend : 

- des moyens pour determiner pour chaque requite d'acces RADIUS re9ue 
25 d'lm serveur d'acces a la demande d'un utilisateur, si une authentification 

locale de I'utilisateur ^metteur de la requete d'acces doit ou non etre 
effectuee au niveau du r6seau local, 

- des moyens pour emettre par Tintermediaire d'un serveur d'acces a 
destination d'un terminal d'utilisateur devant etre authentifie localement, un 

30 message de demande de donnees d'authentification, et pour recevoir en 
reponse du terminal d'utilisateur un message de r6ponse contenant les 
donnees d'authentification demandees, et 

- des moyens pour executer xme procedure d'autiientification locale de 
Tutilisateur, sur la base des informations d'authentification contenues dans le 

35 message de reponse. 



Selon un mode de realisation prefere de Tinvention, le serveur proxy comprend 
en outre des moyens pour determiner un resultat global d'authentification en 
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fonction du resultat de rauthentification locale de Tutilisateur et de la reponse 
d'authentification de Putilisateur foumie par le serveur d'auttientification, et 
pour retransmettre le resultat global d'authentificatioa vers le serveur d'acces. 

5 Selon un mode de realisation pr6fere de rinvention, chaque serveur d'acces 
comprend un client RADIUS et le serveur proxy comprend un client et un 
serveur RADIUS, pour 6changer des messages confonnes au protocole 
RADIUS. 

10 Selon un mode de realisation prefiSre de I'invention, le message de demande de 
donnees d'authentification emis par le serveur proxy pour autfaentifier 
localement Tutilisateur est un message de defi, le serveur proxy comportant des 
moyens pour gen^rer un nombre aleatoire qui est insure dans le message de defi, 
et des moyens pour verifier la reponse au message de defi re9ue du terminal de 

1 5 Futilisateur. 

Selon un mode de realisation prefere de Tiavention, le serveur proxy comprend 
des moyens pour determiner quels droits d'acces attribuer a Futilisateur en 
fonction du resultat des authentifications locale et distante de Futilisateur. 

20 

L'invention conceme en outre un serveur proxy pour autoriser un terminal 
d'utilisateur connecte a xm reseau d'acces a acceder k m foumisseur d'acces ou 
de service IP par Fintermediaire d'un reseau de transport IP relie au reseau 
d'acces par une passerelle IP, le serveur proxy etant connect6 a im reseau de 
25 transport IP et comprenant des moyens pour : 

- retransmettre chaque requdte d'acces RADIUS conforme au protocole 
RADIUS, 6mise par im serveur d'acces a la demande d'un terminal 
d'utilisatem% vers im serveur d'authentification distant de foiunisseur d'acces 

30 ou de service IP indique dans la requite d'acces, et 

- retransmettre vers le serveur d'acces la reponse d'aufbentification foumie par 
le serveur d'authentification distant. 

Selon F invention, le serveur proxy comprend en outre des moyens pour : 

35 

- determiner pour chaque requete d'acces RADIUS repue d'un serveur d'acces 
a la demande d'un utilisateur, si une authentification locale de Futilisateur 
emetteur de la requdte d'acces doit ou non etre effectuee au niveau du reseau 
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localj, 

- emettre par rintermediaire dW serveur d'acces a destination d'un terminal 
d'utilisateur devant etre authentifie localement, im message de demande de 
domiees d'authentification, et pour recevoir en r6ponse du terminal 

5 d'ntilisateur un message de reponse contenant les donnees d'authentification 
demand6es, et 

- ex6cuter une procedure d'authentification locale de Tutilisateur, sur la base 
des informations d'authentification contenues dans le message de reponse. 

10 L'invention conceme 6galement xm programme d'ordinateur destine h etre 
execute par un serveur proxy conpu pour autoriser un terminal d'utilisateur 
connecte a un reseau d'acces a acceder a un foumisseur d'acces ou de service IP 
par rintermediaire d'un reseau de transport IP relie au reseau d'acces par une 
passerelle IP, le serveur proxy etant connecte a un reseau de transport IP, le 

1 5 programme comprenant des instructions pour : 

- retransmettre chaque requete d'acces RADIUS conforme au protocole 
RADIUS 5 emise par un serveur d'acces a la demande d'lm terminal 
d'utilisateur, vers un serveur d'authentification distant de foumisseur d'acces 

20 ou de service IP indique dans la requete d'acces, et 

- retransmettre vers le serveur d'acces la reponse d'authentification foumie par 
le serveur d'authentification distant 

Selon I'invention, le programme comprend en outre des instructions pour : 

25 

- determiner pour chaque requdte d'acces RADIUS re9ue d'un serveur d'acces 
a la demande d'un utilisateur, si une authentification locale de I'utilisateur 
emetteur de la requ8te d'acces doit ou non 6tre effectuee au niveau du reseau 
local, 

30 - emettre par rintermediaire d^un serveur acces a destination d'un terminal 
d'utilisateur devant etre authentifie localement, un message de demande de 
donnees d'authentification, et recevoir en reponse du terminal d'utilisateur 
rni message de reponse contenant les donnees d'authentification demandees, 
et 

35 - executer une procedure d'authentification locale de I'utilisateur, sur la base 
des informations d'authentification contenues dans le message de reponse. 

Un mode de realisation prefere de Tinvention sera decrit ci-apres, a titre 
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d'exemple non limitatif, avec reference aux dessins annexes dans lesquels : 

La figitre 1 represente sch^matiqiiemeiit Tarchitecture d'xm 
systeme de fonrnitiire de services bases sur xm transport IP, selon 
5 rinvention ; 

Les figures 2a et 2b repr6sentent un diagramme de sequencement 
d' Stapes qui sont execut^es dans le systeme represente sur la 
figure 1, confonnement au precede selon T invention. 

Le systeme represente sur la figure 1 comprend des reseaux d^'acces 1, 2 
10 auxquels sont connectes des terminaux 11, 12, 13 d'utilisateurs. Ces reseaux 
d'acces 1^ 2 foumissent aux terminaux un acces a im reseau de transport IP 5 
par rintermediaire de passerelles IP 3, 4, respectives adaptees au reseau 
d' acces. Le reseau de transport IP 5 permet axix utilisateurs d'acceder a un 
foumisseur d'acces Internet 6, 7 ou a un foumisseur de services IP 8. 

15 

Selon rinvention, ce systeme comprend en outre des servexirs d'' acces 9 
connectes respectivement aux reseaux locaux 1^ 2, auxquels les utilisateurs 
souhaitant acceder au reseau IP doivent se connecter, et un serveur proxy 
d'authentification 10 connect6 au reseau de transport IP 5 et auquel chaque 
20 serveur d' acces 9 transmet les requetes d' acces emises par les terminaux 11, 12, 
13. 

Chaque serveur d'accds 9 est conQu poxir recevoir toutes les requetes d' acces a 
un foumisseur 6, 7, 8 d'accfes ou de service, emises par les utilisateurs sur le 
25 reseau local 1, 2 correspondant, et d'aiguiller ces requetes par rintermediaire 
d'lme passerelle 3, 4 au travers du reseau de transport IP vers le foumisseiu" 6, 
7, 8 d' acces ou de service indique dans la requete par le terminal de Tutilisateur, 
chaque foumisseur d'acc^s ou de service disposant d'lm serveur 
d'auihentification 15. 

30 

Lorsqu'un terminal d'utilisateur 11, 12, 13 tente d' acceder au reseau local, le 
logiciel de navigation Intemet est par exemple automatiquement redirige vers 
un serveur Web jouant le role de serveur d' acces 9 qui execute la procedure 
d'authentification d' acces illustree sur les figures 2a et 2b. 

35 

Cette procedure est conforme au protocole RADIUS. Ainsi, le serveur d'acces 9 
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integre im client RADIUS pour pouvoir recevoir des messages RADIUS et y 
repondre, Le serveur proxy 10 possede egalement toutes les fonctioimalites d'un 
proxy tel que decrit dans la norme RADIUS, 

5 Dans toute la description qui suit de la procedure d'authentification, les 
identifiants de messages ou requStes RADIUS employes sont donnes a titre 
d'exemple. Dans la norme RADIUS le terme "type" determine la nature du 
message. 

10 A la premiere etape 21, le serveur d'acces 9 emet a destination du serveur proxy 
d'authentification 10 situS dans le domaine administratif local, une requite 
d'acces 41 du type RADIUS Access-Request comportant un identifiant egal a 
128- A la reception d'un tel message a I'etape 22, le serveur proxy 10 memorise 
et analyse le contenu de ce message pour determiner si Tutilisateur doit etre 

1 5 authentifie localement (etape 23) . 

Ainsi, une authentification locale peut par exemple etre declenchee si la requete 
d'acces provient d'un reseau local particulier, ou en fonction d'informations 
d' identification de Tutilisateur contenues dans la requete. 

20 Si Tutilisateur doit etre authentifie localement, le serveur proxy 10 emet a 
destination du serveur d'acces 9 a T etape 24 un message de defi 44 du type 
RADIUS Access-Challenge comportant un identifiant egal a 128. Ce message 
contient egalement une valeur non predictible par exemple gener6e 
al^atoirement par le serveur proxy 10 ou par un equipement distinct qui peut 

25 Stre un centre d' authentification, et xm attribut pr6cisant Torigine du message, a 
savoir le domaine administratif local. A cet effet, on peut utiliser les attributs de 
type "Vendor-Specific", ou les attributs "State" ou "Reply-Message" pr^vus par 
le protocole RADIUS. 

30 A Petape suivante 25, le serveur d'acces 9 re^oit le message de defi 44, identifie 
Temetteur du message a Paide de F attribut precisant Torigine du message, et 
done demande a Tutilisateur de lui foumir une reponse a la demande 
d' authentification locale. Cette reponse peut contenir une valeur de reponse 
obtenue en appliquant a la valeur aleatoire contenue dans le message de defi un 

35 algorithme de cryptage predefini faisant intervenir une cle secrete propre a 
Tutilisateur, le serveur proxy disposant de moyens pour determiner si la valeur 
de reponse correspond a la valeur aleatoire et h la cle secrete de Tutilisateur. 
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A Tetape suivante 26, le serveur d'acc^s transmet au serveur proxy 10 ime 
nouvelle requete d'acces 46 contetiant la reporise a la demande 
d'authetitification locale, du type RADIUS Access-Request contenant \m 
identifiant egal a 45. 

5 

A Tetape suivante 27, le serveur proxy 10 repoit du serveur d'acces la repouse h 
rauthentification locale, foumie par rutilisateur, la verifie et la memorise. Si a 
r6tape suivante 28, la reponse est invalide (rauthentification locale a echoue), 
le serveur proxy pent refaire ime tentative d'aufhentification en reprenant la 

10 procedure a Tetape 24. Si rauthentification locale de I'utilisateur n'a pas reussi 
a Tissue d'lm nombre predefini de tentatives, le serveur proxy 10 pent selon la 
politique d' administration locale, envoyer a I'utilisateur par Tintermediaire du 
serveur d'acces 9 un message de rejet du type RADIUS Access-Reject, ou 
poursuivre la procedure a Fetape 30 pour permettre a Tutilisateur d'etre 

15 authentifie par un serveur d'authentification distant 15 mis en oeuvre par un 
foumisseur d'acces ou de services auquel Tutilisateur veut acceder. 

Si a Tetape 23 Tutilisateur ne doit pas etre authentifie localement, la procedure 
se poursuit egalement a Tetape 30. A cette etape, le serveur proxy 10 emet a 
20 destination d'un serveur d'authentification distant 15 aupres duquel Tutilisateur 
souhaite etre authentifie, une requete d'acces 50, du type RADIUS Access- 
Request contenant un identifiant egal a 3 1, si le serveur 15 est de type RADIUS. 
Ce message est constitue a partir des informations contenues dans la requete 
d'accds 41 memorisee par le serveur proxy 10 I'^tape 22. 

25 

A l'6tape suivante 31, le serveur d'authentification distant 15 repoit et analyse 
ce message pour determiner le droit d'accds au service demande par 
Tutilisateur. A 1' etape suivante 32, le serveur d'authentification emet im 
message de reponse 52 qui pent 8tre un message d' acceptation, de rejet ou de 
30 defi, selon les informations d'authentification contenues dans le message 50 
rcQU. Ainsi, conformement au protocole RADIUS, le message 52 pent gtre de 
type Access-Accept, Access-Reject ou Access-Challenge et contient un 
identifiant egal a 3 1 correspondant a I'identifiant du message 50 regu. 

35 Les etapes suivantes de la procedure dependent de deux conditions (etape 33), a 
savoir si rauthentification locale de I'utilisateur a etc demandee au prealable ou 
non, et si rauthentification locale a ete demandee, si celle-ci a reussi ou echoue. 
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Si rauthentification n'a pas ete demandee au prealable, le serveur proxy 10 qui 
regoit le message 52, traite ce message a Tetape 34 et envoie un message 54 au 
serveur d'acces 9. Ce message 54 correspond a une reponse au message 41 emis 
a I'etape 21 par le serveur d'acces. Ces messages comportent par exemple 
5 ridentifiant 128 (cas a) dans la figure 2b). Ainsi, si le message 52 6mis par le 
serveur d'authentification distant 15 est im message d' acceptation (RADIUS 
Access- Accept), le serveur proxy 10 renvoie au serveur d'accds 9 un message 
d' acceptation (RADIUS Access- Accept). Si le message 52 emis par le serveur 
d'authentification distant 15 est un message de refus (RADIUS Access-Reject), 

10 le serveur proxy 10 renvoie au serveur d'acces 9 un message de refus (RADIUS 
Access-Reject) ou un message d' acceptation selon la politique locale du serveur 
proxy. Le message 52 pent egalement etre un message de defi si 
rauthentification de Tutilisateur par le serveur d'authentification distant 15 a 
echoue, ou si ce dernier a besoin de davantage d' informations d'authentification 

15 ou souhaite appliquer un mecanisme dynamique d'authentification. Dans ce cas, 
le message 54 transmis au serveur d'acces est un message de defi (RADIUS 
Access-Challenge) . 

A la reception du message 54 a I'etape 35, le serveur d'acces analyse le contenu 
20 du message, et s'il s'agit d'un message d' acceptation ou de refus, la procedure 
d'authentification prend fin et le serveur d'acces configure I'acces de 
Tutilisateur au reseau local 1, 2, et au reseau IP 5 en fonction de la reponse du 
serveur proxy 10. Si le message 54 est un message de d6fi, le serveur d'accds 
demande h Futilisateur a I'etape 36 de foumir une reponse a la demande 
25 d'authentification du domaine adniinistratif distant. A I'etape suivante 37, le 
serveur d'acces constitue une requ8te d'accds 57 contenant la reponse de 
I'utilisateur et I'envoie au serveur proxy 10. Cette requete d'accds est vm 
message RADIUS Access-Request avec un identifiant egal a 10 (cas b) dans la 
figure 2b). 

30 

A I'etape suivante 38, le serveur proxy revolt le message 57 et le retransmet au 
serveur d'authentification distant 15 dans un message de requete 58, sous la 
forme d'xm message RADIUS du type Access-Request avec un identifiant egal 
a 24 (cas c) dans la figure 2b). A I'etape suivante 39^ le serveur 15 re5oit et 
35 analyse le contenu du message 58 et emet a I'etape 40 suivante un message de 
reponse 60 dont le contenu depend de la reussite de rauthentification effectuee 
par le serveur 15. Ce message conserve 1' identifiant 24 (cas d) dans la figure 
2b). Ainsi, le message 60 pent etre un message d'acception (RADIUS Access- 
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Accept), de refos (RADIUS Access-Reject) ou un nouveau message de defi 
(RADIUS Access-Challenge) 

La procediure d'authentification reprend ensuite a partir de I'etape 34 au cours 
5 de laquelle le serveiir proxy 10 traite et retransmet le message 60 re9U au 
serveur d'acces sous la forme d'un message 54. L'identifiant du message 60 
regu, egal a 24, est remplace par 10 pour correspondre a ceM 57 emis par le 
serveur d'acces 9 (cas e) dans la figure 2b). 

10 La procedure d'authentification se teraiine a I'etape 35 si le message 54 qui est 
transmis au serveur d'acces 9 est im message d' acceptation ou de refiis et 
contient le r6sultat de I'authentification effectuee par le serveur 
d^'authentification distant 15 (pas d'authentification locale). Si par centre le 
message 54 est xm nouveau message de defi, la procedure se poursuit a I'etape 

15 36. 

Si a I'etape 33, rauthentification locale a ete demandee et a reussi, la procedure 
comprenant les etapes 34 a 40 est egalement executee, mais avec des messages 
contenant des numeros d'identification differents (messages correspondants aux 

20 cas al) a el) dans la figure 2b). Ainsi, le message 52 contenant Pidentifiant 31 
est transforaie a I'etape 34 par le serveur proxy en \m message 54 contenant 
I'identifiant 45 et le resultat de 1' identification locale. A I'etape 37, 1'identifiant 
45 du message 57 devient 20. A I'etape suivante 38, I'identifiant 20 du message 
58 devient 48. A I'etape 40, I'identifiant 48 reste inchange. A I'etape suivante 

25 34, I'identifiant 48 du message devient 20. 

La procedure d'authentification se termine a I'etape 35 si le message 54 qui est 
transmis au serveur d'acces 9 est du type acceptation ou refus, contenant un 
attribut precisant le resultat des authentifications locale (reussite) et distante. Si 
30 par centre le message 54 est im nouveau message de defi, la procedure se 
poursuit a I'etape 36, 

A Tissue de la procedure d' authentifications si Tauthentification distante a 
reussi, le message 54 est de type acceptation, et si elle a echoue, ce message 
35 pent etre de type acceptation ou refus selon la politique d' administration locale. 

Si a I'etape 33, I'authentification locale a ete demandee et a echoue, la 
procedure comportant les etapes 34 h 40 est egalement executee, avec des 
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messages contenant des numeros d' identification differents (messages 
correspondants aux cas a2) a e2) dans la figure 2b). Ainsi, le message 52 
contenant I'identifiant 31 est transfomie a Tetape 34 par le serveur proxy en un 
message 54 contenant I'identifiant 45 et le r6s\iltat de identification locale. A 
5 Petape 37, Pidentifiant 45 du message 57 devient 30. A I'etape snivante 38, 
ridentifiant 30 du message 58 devient 96. A I'etape 40, I'identifiant 96 teste 
inchange. A I'etape suivante 34, I'identifiant 96 du message devient 30. 

La procedure d'authentification se temiine a I'etape 35 si le message 54 qui est 
10 transmis au serveur d'acces 9 est du type acceptation ou refiis, contenant im 
attribut precisant le resultat des authentifications locale (echec) et distante. Si 
par contre le message 54 est un nouveau message de defi, la procedure se 
poursuit a I'etape 36. 

15 A I'issue de la procedure d'authentification, le message 54 qui est envoye au 
serveur d'acces 9 peut etre de type acceptation (meme si les authentifications 
locale et distante ont echoue) ou refias selon la politique d' administration locale. 

En fonction du resultat de la procedxire d'authentification, le serveur d'acces 9 
20 configure ensuite I'acces de I'utilisateur d'une maniere adequate et peut 
I'informer sur le type de connexion a laquelle il a droit. 

Grace k ces dispositions, les procedures locale et distante d'authentification 
d'un utilisateur sont totalement independantes. Chaque domaine administratif 
25 est done totalement libre d'imposer ou non une procedure d'authentification. 

Dans un mode de realisation de I'invention, on utilise deux attributs du type 
"Vendor Specific" des messages RADIUS prevus dans le protocole. Le premier 
de ces deux attributs appele "Local_Challenge" est inclus dans les messages de 

30 defi envoyes par le serveur proxy 10 au serveur d'acces 9. Get attribut est utilise 
pour indiquer au serveur d'acces si oui ou non il est a I'origine du message. En 
fonction de la presence ou non de cet attribut, le serveur d'acces precise a 
Tutilisateur s'il s'agit d'une authentification locale ou distante pour obtenir ime 
reponse adequate a un message de defi. 

35 Le second attribut appele "Auth_Status" est inclus dans les messages 
d' acceptation envoyes par le serveur proxy pour cloturer la procedure 
d'authentification de I'utilisateur et pour indiquer au serveur d'acces les 
resultats d'authentification locale et distante. 
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Cette procedure est parfaitement adaptee a un acces au reseau Internet par 
rintemi6diaire d'lm reseau local ouvert de type WLAN, par exemple Wi-Fi, 
dont r acces est contr61e par son proprietaire. Ce reseau local pent proposer des 
5 services locaux, tels que des services de foumiture d' informations sur le lieu ou 
le r6seau local est accessible, par exemple des plans, des listes d'adresses utiles, 
etc. Pour acc6der au reseau Intemet, les utilisateurs qui se connectent a ce 
reseau local doivent en outre proceder a une demande d'acces aupres de leur 
foumisseur d' acces. 

10 

Lorsqu'im utilisateur muni d'un terminal se trouve dans la zone de couverture 
du reseau local WLAN, et qu'U lance le logiciel de navigation, celui-ci est 
automatiquement redirige sur un serveur Web du serveur d' acces local 9. Dans 
une page d'accueil du serveur Web, les utilisateurs sont invites a introduire un 
15 identifiant et un mot de passe d' acces au reseau local s'ils en ont un. S'ils 
souhaitent acceder au reseau Intemet, ils doivent selectionner un foumisseur 
d' acces dans ime liste, puis introduire un identifiant et un mot de passe d' acces 
correspondant au foumisseur d' acces selectionne. 

Les informations saisies par Tutilisateur sont transmises par le serveur d'acces 9 
20 au serveur proxy 1 0 du reseau local. 

Si I'utilisateur a introduit un identifiant et un mot de passe d' acces au reseau 
local, le serveur proxy 10 du reseau local declenche la procedure 
d' identification locale et garde en memoire le resultat de cette authentification. 
25 Puis il declenche la procedure d' authentification de Tutilisateur aupres du 
serveur d' authentification 15 du foumisseur d' acces selectionne par 
I'utilisateur. 

Selon le resultat des authentifications locale et distante, le serveur proxy envoie 
30 un message d' acceptation, ou de refus si les authentifications locale et distante 

ont toutes les deux echoue. Dans ce dernier cas, le serveur d' acces n'autorise 

pas Tutilisateur a acceder a des services locaux ou distants. 

Si Tutilisateur a ete authentifie uniquement localement ou uniquement aupres 

du foumisseur d' acces, le serveur d' acces ne lui domie acces qu'aux services 
35 correspondants. Et si les deux authentifications ont reussi, le serveur d'acces 

donne acces a Futilisateur a la fois aux services locaux et distants. 

De m8me, si Tutilisateur n'a pas demande xme authentification locale, seule une 
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authentification distante est effectuee, et si celle-ci reussit^, le serveur d'acces lui 
configure xm acces au reseau Internet. 

La qualite de service QoS attribuee k I'utilisatenr dans le reseau local pent 
5 egalement 6tre adaptee par le serveur d'acc^s 9 en fonction du resultat de 
Tauthentification locale. 



wo 2005/086454 



PCT/FR2005/000206 



-16- 

REVENDICATIONS 

1. Precede de gestion d'autorisation d'un utilisateur lors d'une 
tentative d'acces a un reseau de transport IP (5) par rintermediaire d'un reseau 

5 d'acces (1,2), ce precede comprenant des etapes au coTirs desquelles : 

- un terminal (11, 12, 13) d'utilisateiir 6met a destination d'lin foumisseur 
d'acces ou de service IP (6, 7, 8) une requete d'acces contenant des donnees 
d'authentification de Tutilisateur auprds du foumisseur d'acces ou de service 
IP, qui est transmise par rintermediaire d'un serveur d'acces (9) du reseau 

10 d'acces (1, 2) et du reseau de transport IP (5), en vue d'etre adress6e k un 
serveur d'authentification distant (15) du foumisseur d'acces ou de service 
IP, 

- sur reception de la requSte dacces, le serveur d'acces (9) emet ime requ6te 
RADIUS conforme au protocole RADIUS a un serveur proxy (10) du reseau 

15 d'accds (1, 2), 

- sur reception de la requete RADIUS, le serveur proxy emet une demande 
dautorisation d'acces au serveur dauthentification distant (15), 

- le serveur d'authentification distant (15) execute xme procedure 
d'authentification de I'utilisateur, sur la base des donnees d'authentification 

20 contenues dans la requete d'acces, et transmet en reponse au seiveur proxy 
un message de reponse contenant le resultat de la procedure 
d'authentification de I'utilisateur, 
caracterise en ce qu'il comprend en outre des etapes au cours desquelles : 

- le serveur proxy determine pour chaque requete RADIUS, repue du serveur 
25 d'acces (9) et correspondant a une requSte d'acces 6mise par un terminal 

d'utilisateur, si xme authentification locale de I'utilisateur 6metteur de la 
requSte d'acces, au niveau du reseau local (1, 2) doit 6tre effectuee, 

- si une authentification locale de I'utilisateur doit etre effectuee, le serveur 
proxy emet a destination du serveur d'acces (9) une demande de donnees 

30 d'authentification qui est retransmise au terminal de Tutilisateur, regoit im 
message de reponse du terminal d'utilisateur par rintermediaire du serveur 
d'acces, et execute une procedure d'authentification locale de rutilisateur, 
sur la base des donnees d'authentification contenues dans le message de 
reponse. 

35 

2, Procede selon la revendication 1, 

caracterise en ce que la demande de donnees d'authentification emise par le 
serveur proxy (10) a destination du terminal de I'utilisateur (11, 12, 13) si une 
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authentification locale de rutilisateur doit etre effectuee, est un message de defi 
contenant un nombre aleatoire. 

3. Procede selon la revendication 2, 

5 caracteris6 en ce que le message de d6fi contient une indication permettant au 
temiinal de Tutilisateur de detemiiner qu'il conceme une authentification locale 
de rutilisateur. 

4. Procede selon Tune des revendications 1 a 3, 

10 caracteris^ en ce que T authentification distante de Tutilisateur par le serveur 
d' authentification distant (15) comprend des etapes au cours desquelles : 

- le serveur d' authentification distant emet en direction de Tutilisateur un 
message de defi contenant xm nombre aleatoire, 

~ le serveur proxy (10) retransmet le message de defi emis par le serveur 
15 d' authentification distant en direction de rutilisateur et re9oit dans un 
message de reponse les domiees d' authentification de rutilisateinr aupres du 
serveur d' authentification distant, 

- le serveur proxy (10) retransmet au sers^eur d' authentification distant le 
message de reponse emis par le terminal de Tutilisateur, 

20 - le serveur proxy (10) re?oit du serveur d' authentification distant un message 
de resultat de T authentification de Tutilisateur. 

5* Procede selon Time des revendications 1 a 4, 
caract6rise en ce que le serveur proxy (10) determine quels droits d'acces 
25 attribuer k I'utilisateiir en fonction du resultat des authentifications locale et 
distante de Tutilisateur. 

6. Systeme de gestion d'autorisation d'un utilisateur lors d'lme 
tentative d'acces d'xm terminal d'utiUsateur a un foumisseur d'acces ou de 
30 service IP (6, 7, 8) par Tintennediaire d'un r6seau de transport IP (5), le 
systeme comprenant : 

- des reseaux d'acces (1, 2) auxquels sont connectes les terminaux 
d'utilisateurs, 

- des passerelies IP (3, 4) assurant la liaison respectivement entre les reseaux 
35 d'acces (1, 2) et le reseau de transport IP (5), 

- au moins un serveur d'acces (9) par reseau d'acces, congu pour emettre a la 
demande des terminaux d'utilisateur des requetes d'acces RADIUS 
conformes au protocole RADIUS, 
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- au moins un serveur d'authentification distant (15) pour chacun des 
foumisseurs d' access ou de service IP (6, 7, 8), congu pour authentifier les 
utilisateurs en fonction de donnees d'authentification contenues dans des 
requStes d'acces (50, 58) revues par le serveur d'authentification, et 

5 - un serveur proxy (10) connecte au r6seau de transport IP conpu pour 
retransmettre chaque requete d'acces RADIUS, emise par Tun des serveurs 
d'accds (9) a la demaade d'un utilisateur, vers un serveur d'authentification 
distant (15) de foumisseur d'acces ou de service IP indique dans la requete 
d'acces, et retransmettre vers les servexirs d'acces les reponses 
10 d' authentification foumies par les servexirs d' authentification distant (1 5), 
caracterise en ce que le serveur proxy (10) comprend : 

- des moyens pour determiner pour chaque requete d'acces RADIUS re^ue 
d'un serveur d'acces (9) a la demande d'un utilisateur, si une authentification 
locale de I'utilisateur emetteur de la requete d'acces doit ou non etre 

1 5 effectuee au niveau du reseau local (1,2), 

- des moyens pour emettre par Tintemiediaire d'un serveur d'acces a 
destination d'un terminal d'utilisateur devant etre authentifie localement, un 
message de demande de donnees d'authentification, et pour recevoir en 
r6ponse du terminal d'utilisateur im message de reponse contenant les 

20 donnees d'authentification demandees, et 

- des moyens pour executer une procedure d'authentification locale de 
I'utilisateur, sur la base des informations d'authentification contenues dans le 
message de reponse. 



25 7. Systdme selon la revendication 6, 

caracterise en ce que le serveur proxy (10) comprend en outre des moyens pour 
determiner un resultat global d'authentification en fonction du resultat de 
r authentification locale de I'utilisateur et de la reponse d'authentification de 
Futilisateur foumie par le serveur d'authentification (15), et pour retransmettre 

30 le resultat global d'authentification vers le serveur d'acces (9). 

8. Systeme selon la revendication 6 ou 7, 

caracterise en ce que chaque serveur d'acces (9) comprend un client RADIUS et 
le serveur proxy comprend un client et un serveur RADIUS, pour echanger des 
35 messages conformes au protocole RADIUS. 

9. Systeme selon Time des revendications 6 a 8, 

caracterise en ce que le message de demande de donnees d'authentification 
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emis par le serveur proxy (10) pour authentifier localement Tutilisateur est un 
message de defi, le serveur proxy comportant des moyens pour generer un 
nombre al6atoire qui est insert dans le message de d6fi, et des moyens pour 
v6rifier la r6ponse au message de defi regue du terminal de I'utilisateur. 

5 

10. Systeme selon Tune des revendications 6 9, 

caract6ris6 en ce que le serveur proxy (10) comprend des moyens pour 
determiner quels droits d'accds attribuer a I'utilisateur en fonction du resultat 
des authentifications locale et distante de TutLlisateur. 

10 

11. Serveur proxy (10) pour autoriser im terminal d'utilisateur 
connect^ h un reseau d'acces (1, 2) a acceder a un foumisseur d'acces ou de 
service IP (6, 7, 8) par I'iatermediaire d'un reseau de transport IP (5) relie au 
reseau d'acces par une passerelle IP (3, 4), le servexir proxy 6tant connecte a im 

1 5 reseau de transport IP et comprenant des moyens pour : 

- retransmettre chaque requete d'acces RADIUS (50, 58) conforme au 
protocole RADIUS, emise par un serveur d'acces (9) a la demande d'un 
terminal d'utilisateur, vers un serveur d'authenttfication distant (15) de 
foumisseur d'acces ou de service IP indiqu6 dans la requSte d'acces, et 

20 - retransmettre vers le serveur d'accds la r^nsed'authentificationfoumie par 

le serveur d'authentification distant (15), 
caracteris6 en ce qu'il comprend en outre des moyens pour : 

- determiner pour chaque requ6te d'accds RADIUS re^ue d'lm serveur d'acces 
(9) h la demande d'un utilisateur, si une authentification locale de 

25 I'utilisateur 6metteur de la requSte d'acces doit ou non etre effectu6e au 
niveau du reseau local (1,2), 

- emettre par Tintermediaire d'un serveur d'acces a destination d'un terminal 
d'utilisateur devant etre authentifi6 localement, un message de demande de 
donnees d'authentification, et pom- recevoir en reponse du terminal 

30 d'utilisateur un message de reponse contenant les domi6es d'authentification 
demandees, et 

- executer ime procedure d'authentification locale de I'utilisateur, sur la base 
des informations d'authentification contenues dans le message de reponse. 

35 12. Programme d'ordiaateur destine a Stre ex6cut6 par im serveur 

proxy (10) con9U pour autoriser un terminal d'utilisateur connect^ h \m r6seau 
d'acces (1, 2) a acceder ^ un foumisseur d'accds ou de service IP (6, 7, 8) par 
rintenn6diaire d'un reseau de transport IP (5) reli6 au r6seau d'accds par une 
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passerelle IP (3, 4), le serveur proxy etant connecte a un reseau de transport IP, 
le programme comprenant des instructions pour : 

- retransmettre cliaque requete d'acc^s RADIUS (50, 58) conforme au 
protocole RADIUS, emise par nn serveur d'acces (9) a la demande d^un 

5 terminal d'utilisateur, vers un serveur d'authentification distant (15) de 
foumisseur d'acces ou de service IP indique dans la requete d'acces, et 

- retransmettre vers le servenr d'acc^s la reponse d'authentification foumie par 
le serveur d'authentijScation distant (15), 

caract6rise en ce qu'il comprend en outre des instructions pour : 
10 - determiner pour chaque requSte d'acc^s RADIUS refue d'un serveur d'acces 
(9) a la demande d'un utilisateur^ si ime authentification locale de 
Tutilisateur ^metteur de la requ6te d'acces doit ou non 6tre effectuee au 
niveau du reseau local (1, 2), 

- emettre par Tintermediaire d'un serveur d'acces a destination d'lm terminal 
15 d'utilisateur devant 6tre authentifie localement, un message de demande de 

dorttiees d'authentification, et recevoir en reponse du terminal d'utilisateur 
un message de reponse contenant les donuees d' authentification demandees, 
et 

- ex6cuter xme procedure d' authentification locale de Tutilisateur, sur la base 
20 des informations d'authentification contenues dans le message de reponse. 
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